The idea with postfixapostrophize is that users can define methods for it, for their own types, and be able to use ' (rather than defining a method for Adjoint which might not make any sense). Perhaps @Sacha0 can shed some more light on this too

Ok, I can work with that. How about calling it apostrophe instead?

Thanks for fixing the overwrite Jeff! :)

As Fredrik mentioned, the aims of lowering to postfixapostrophize rather than Adjoint were to: (1) enable other uses of postfix ' without punning Adjoint; and (2) better separate the concerns of base and linalg.

Regarding spelling, I injected the qualification postfix for three reasons: (1) apostrophes see non-postfix use (e.g. for characters); (2) defining and/or calling this function should be rare, so length should not matter but explicitness and clarity do; and (3) if in the future apostrophes gain other uses, this name should remain clear. I selected the verb apostrophize rather than the noun apostrophe to reflect the function's semantics, i.e. application of a postfix apostrophe. Best!

I don't really find postfixapostrophize that clear; it looks like letter salad to me. I also don't think ' will or should gain more uses, but we can cross that bridge when we get to it.

I don't really find postfixapostrophize that clear; it looks like letter salad to me.

However you will then, I lack strong sentiments :).

For MethodTable, are you sure this is the right fix? If someone else wants that functionality, it could easily take an hour of poking around to discover how to reliably go from a method to the corresponding method table---given the implementation, it's hard to argue that the right steps are obvious. This approach was easily discoverable and did not add to the exports. Why not add a @skipwarning?

In #25222 I just moved it to methodshow.jl.

There's been some discussion that ' should perhaps lower directly to adjoint, so this is still a bit up in the air.

@Sacha0 and I decided that we should probably make adjoint and transpose lazy by default, and make (') === adjoint.

Did you also discuss what A' should result in without using LinAlg when LinAlg is in stdlib?

No, but it would not be ideal for A' to change based on whether LinAlg has been loaded.

Agree, I think that A' should give an informative error about the need for using LinAlg or whatever. And I think that LinAlg should be the owner of adjoint, so we need something like apostrophe in Base that we can lower A' to, right? Then LinAlg would simply have Base.apostrophe(A) = adjoint(A).

Or Base could contain an adjoint function with no methods.

Any more thoughts on whether LinAlg could be more than one package? Maybe one with basic definitions like adjoint, one for BLAS, and then MatrixFactorizations? I think needing to load a package before A' works is not a good user experience, but we also don't want to have to load everything by default.

Sharding LinAlg a bit sounds great. Seems like post-1.0 work though? Best!

I have to say, while I understand how we got here, needing to do import LinAlg in order to use A' makes me rather sad. If it wasn't syntax it would feel so unfortunate.

Ah, I've been assuming that LinAlg will be loaded by default at the REPL, so that the import LinAlg isn't necessary?

This is a bit subtle. The code for stdlib is pre-loaded, but you would have to do using to get the names it exports. In this case, however, ' is already defined in Base. However, relying on it being pre-loaded means that we can't really decouple it later. Maybe that's fine and it will force us to separate the parts of LinAlg that provide functionality in Base versus parts of it that only exist to implement functionality that is exported from LinAlg.

We do have the option of putting using LinAlg in the default juliarc. But I still think it makes sense to separate LinAlg into commonly-used stuff like dot products, vs. more obscure matrix factorizations.

I could see MatrixTypes and MatrixFactorizations stdlib packages.